Blog

Brad Wood

October 25, 2012

Spread the word


Share your thoughts

One of the most common server configurations is to have a production server and then 1 or more development or testing servers.  The trick with your "lower" environments is you typically want different settings for logging, error messages, data sources, or outgoing E-mails.  Manually switching settings when you move code is sketchy at best and setting up deployment scripts can be more work than you're willing to take on.
 
Enter ColdBox Environment Control.  ColdBox makes it easy to have different settings for each environment.  In your configuration CFC, you have a configure() method that creates several structs of setting variables.  Let's consider these our default production values.  Next, all you do is create a method for each additional environment such as development(), stage(), etc.  ColdBox will automatically call the appropriate environment override and you can add, remove, or override settings for that environment as you see fit.
 
In the mock example below, you can see that the main production settings are in the configure() method.  The "environments" setting struct declares a list of regular expressions to match against the URL to determine the environment.  When not in production, the appropriate development() or stage() method will be called where it can override or add settings as it sees fit.
 
ColdBox.cfc
component {
 
    function configure() {
        coldbox = {
            setting1 = 'value1',
            setting2 = 'value2',
            setting3 = 'value3'
        };
 
        environments = {
            development = "^dev.,^local.",
            stage = "^stage.,^test."
        };
    }
    
    function development() {
        coldbox.setting1 = 'devValue';
        arrayAppend(interceptors, {class="coldbox.system.interceptors.ColdboxSidebar} );
    }
    
    function stage() {
        coldbox.setting1 = 'stageValue';
    }
}
 
 
P.S. Don't want to use URL to determine your environment?  No problem.  Instead of an environments struct in your config, create a method called detectEnvironment() and simply have it return a string corresponding with the correct environment for that server.  You can base off the machine name, IP address, or even the location of the code on the file system.  It's up to you!

Add Your Comment

(2)

Oct 25, 2012 10:58:35 UTC

by Peter Boughton

Since it's a regex matched against http_host, you need to escape the dot - i.e. development = "^dev\.,^local\.", (Otherwise the dot will match any char in the hostname, so a domain such as "device.com" would incorrectly be considered development.)

Oct 25, 2012 15:16:41 UTC

by Brad Wood

Peter, funny you mentioned that. I've used it that way for years and never noticed, but it occurred to me last night while I was typing this up that the period needed escaped. I left it that way to match the docs, but you have a very good point. I think the saving grace, is that most people have a limited number of host names pointed at their apps.

Recent Entries

12 Days of BoxLang - Day 4: TestBox

12 Days of BoxLang - Day 4: TestBox

Today we’re celebrating one of the most exciting new additions to the BoxLang ecosystem:

the TestBox BoxLang CLI Runner — a fast, native way to run your TestBox tests directly through the BoxLang Runtime. ⚡

No server required. No CommandBox needed. Just pure, ultra-fast BoxLang-powered testing from the command lineon Windows, Mac, and Linux.

If you’re building modern applications with BoxLang — web apps, CLIs, serverless functions, Android apps, or OS-level utilities — this new feature gives you a unified, flexible testing workflow you can run anywhere.

Victor Campos
Victor Campos
December 13, 2025
12 days of BoxLang - Day 3: SocketBox!

12 days of BoxLang - Day 3: SocketBox!

As BoxLang continues evolving into a modern, high-performance, JVM-based runtime, real-time communication becomes essential for the applications we all want to build: dashboards, collaboration tools, notifications, live feeds, multiplayer features, and more.

That’s where SocketBox steps in — the WebSocket upgrade listener built to work seamlessly with CommandBox and the BoxLang MiniServer. ⚡

Today, for Day 3, we’re highlighting how SocketBox supercharges BoxLang development by giving you fast, flexible, and framework-agnostic WebSocket capabilities.

Maria Jose Herrera
Maria Jose Herrera
December 12, 2025
12 Days of BoxLang - Day 2: CommandBox

12 Days of BoxLang - Day 2: CommandBox

BoxLang + CommandBox: The Enterprise Engine Behind Your Deployments

For Day 2 of our 12 Days of Christmas series, we’re diving into one of the most powerful parts of the BoxLang ecosystem: CommandBox the defacto enterprise servlet deployment platform for BoxLang.

If BoxLang is the language powering your applications, CommandBox is the engine room behind it all. ⚙️

Victor Campos
Victor Campos
December 11, 2025